1. Field of the Invention
The invention relates to a method for generating a code, particularly a production code, from a reference model, for use in an electronic control unit for vehicles.
2. Description of the Background Art
The term “reference model” typically refers to a model or submodel for generating a code, whereby the reference model according to the invention describes a model available to a developer of a particular control unit (electronic control unit, ECU). The reference model is used here to model the (algorithmic) behavior or subfunctions of an electronic control unit for the purpose of model-based software development.
The term “code” typically describes the program code, generated from the model, for an embedded system. The modeled algorithm in this case is implemented in the code, so that the behavior of the generated code corresponds to the behavior of the model. A known program for code generation from such models is, for example, TargetLink used in the Simulink graphical development environment.
The term “production code” typically refers to program code, which has been adapted to the quality and efficiency criteria of a specific hardware and software platform employed in a real-world system. Thereby is to be distinguished from for example prototyping code.
The term “electronic control unit” can be understood as a control system, thus, for example, a control device for a motor vehicle. Such a control unit has a particular combination of hardware and software. Thus, a control unit can also have an operating system or other software functionalities, which can then be further supplemented. The electronic control unit can be used thereby, for example, for measuring, controlling, regulating, and/or calibrating vehicle components.
The term “vehicle” can be used as an inclusive designation for watercraft, land vehicles, aircraft, spacecraft, and/or combinations thereof.
In the environment of the model-based software development for embedded systems, it is common to have an external developer carry out the code generation and/or control device development from models or submodels.
To this end, typically the first-party developer himself generates from a model to be protected the code that is then sent to the second-party developer and can be used by the latter for simulation and combination with a further code to compile a complete code for the later control device hardware. This has the advantage that the second-party developer cannot see the model as such. It is nevertheless disadvantageous in this case that this code provided by the first-party developer can be adapted only to the source code level, which in the case of a necessary adaptation for integration into the code, which is available or to be generated additionally by the second-party developer, for a specific control unit first requires switching to just this level.
In order to address the need for such measures during code generation by the first-party developer, the possibility was created to generate a completely invisible model from the model to be protected and to incorporate as it were unadapted the code, generated thereby from the protected model by the first-party developer, at the second-party developer during the complete code generation from a higher-order model. This means that the code generated by the first-party developer is automatically integrated into the environment code during code generation in the development environment of the second-party developer. It is disadvantageous here as well, however, that the final adaptation to the control unit to be used and its hardware specification can occur only by adaptation at the source code level or by additional frame code, which carries out the adaptation.
In the first case the already described break in the consistency between model and code is a disadvantage; in the second case the efficiency (runtime performance) of the system is reduced by the additional code and the cost (RAM/ROM usage) is increased. The optimization potential by hardware-specific code generation is also not utilized.
The solution to the above-described situation known from the conventional art is to transmit the model in plain text, in order to enable adaptation later by the second-party developer, and subsequently to develop adapted code therefrom. In so doing, however, it is not possible to protect the model and the intellectual property associated therewith.
A further conventional solution is that the second-party developer provides the first-party developer its development environment and the first-party developer can thus generate an adapted code. The latter can again provide this in source code or also as object code to the second-party developer for integration. Nevertheless, the first-party developer would then assume the responsibility for the correctness of the code, which again would be undesirable or also not at all possible because of lack of technical competence.